Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in PR #7, the data items in the upstream module caused issues with planning. We don't need the heritage records from the aws-dns module either....
digging deeper, it seems we haven't been using cname/alias records. They are different than strict cnames -> https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
the aws module docs have a note:
Exactly one of records or alias must be specified: this determines whether it's an alias record.in my 15s of research, every place we have created lb cnames we used a cname record, and the module for cname records isn't using alias.
There is a minor cost savings from this - alias record queries are not charged ->
Route 53 doesn't charge for alias queries to AWS resources. For more information, see [Amazon Route 53 Pricing](https://aws.amazon.com/route53/pricing/).Additional information regarding comparison of alias and cname records -> https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html#resource-record-sets-choosing-alias-non-alias-comparison